疑難雜症萬事通
在網路上遇到任何問題都可以在這邊找找看唷

Search

關於 設計 重 構 25個管理技術債的技巧消除軟體設計 臭 味 ，我們在網路上蒐集到這些相關的討論、資訊與評價

相關標籤 相關照片 相關影片

「設計 重 構 25個管理技術債的技巧消除軟體設計 臭 味」的推薦目錄：


社群媒體上有些相關的討論：

設計 重 構 25個管理技術債的技巧消除軟體設計 臭 味 在 [討論] 重構之前要寫測試不然不要重構- 看板Soft_Job 的推薦與評價


作者Ghamu (貓丸)
看板Soft_Job
標題[討論] 重構之前要寫測試 不然不要重構
時間Thu Jul 2 02:48:37 2020


想想這應該算是一種迷思吧

理論上是這樣沒錯

但事實上之前都沒寫測試了

你怎麼證明他之前是對的呢?

所以我大多都直接給他改下去

反正重構後東西也比較清楚

即使有錯 也比起蝦雞巴狗爛毛程式碼好除錯

之前前輩都說會動的程式碼不要去碰

然後就一球在那邊

我說要改 他就說

[啊你有寫測試嗎?]

開發時程又不允許

就一球在那邊越來越痛苦

會動的爛程式碼越來越多

不知道大家怎麼看

-----
Sent from JPTT on my Sony F5321.

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 101.15.130.230 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1593629319.A.05A.html
※ 編輯: Ghamu (101.15.130.230 臺灣), 07/02/2020 02:52:31
推 ousapas: 如果是老程式碼可以把手測流程自動化成functional test 07/02 04:01
→ ousapas: 不用執著於一定要寫unit test 07/02 04:01
→ ousapas: 如此一來不須要100% coverage也能安心重構 07/02 04:02
推 keyboard56: 證明他是對的這件事因為在正式環境運行一段時間了沒 07/02 07:25
→ keyboard56: 有使用者反應問題，基本上就是證明他沒錯 07/02 07:25
噓 chchang0820: 你怎麼證明他之前寫的是對的?是不是連需求都不清楚 07/02 07:26
推 NDark: 不是證明是對的。是要證明改前後的輸出是一樣的。 07/02 07:29
→ NDark: 很多情況是函式Ａ寫錯除二 Ｂ只好跟著錯乘二 補回來 07/02 07:30
→ NDark: 這時候只重構Ａ或是只重構Ｂ都不能把錯誤"改正" 07/02 07:31
→ NDark: 因為無法確定是不是只有Ｂ會吃到Ａ的結果。 07/02 07:31
→ keyboard56: 全新的需求就可以跟使用者來回確認。重構跟開發全新 07/02 07:32
→ keyboard56: 需求是兩件事，你沒辦法在跟使用者去確認，所以你只 07/02 07:32
→ keyboard56: 能自己確認 07/02 07:32
噓 alihue: 好好寫不行嗎 07/02 07:53
推 GinginDenSha: 好險你沒改到出包 哪天出包你就知道為啥前輩都放著 07/02 08:04
→ GinginDenSha: 不管了 嘻嘻 07/02 08:04
推 shingatter: 公司現在就能賺錢，為什麼要另外花成本重構？ 07/02 08:11
→ shingatter: 測試只是為了得出相同結果的手段，你的目的是想重構 07/02 08:11
→ shingatter: 而不是減少測試。 07/02 08:11
→ shingatter: 你要提出重構的效益說服pm、老闆，而不是前輩，老闆 07/02 08:11
→ shingatter: 覺得重構好就會做了。 07/02 08:11
推 yyhsiu: 覺得樓上說的非常中肯，各種教條要配合想要的結果跟手段 07/02 08:12
→ yyhsiu: 盲從跟隨便說教條是迷思，而不看自己的情況、背後的理由 07/02 08:13
→ yyhsiu: 都不太好 07/02 08:13
推 hidog: 理性是要有測試再重構，但還是要考慮實務問題 07/02 08:18
→ hidog: 理想 打錯字 07/02 08:19
→ x000032001: 去找RD lead決鬥阿 pm懂個小喔 07/02 08:28
→ Murasaki0110: 你要拿你的績效賭誰管得著 07/02 08:50
推 vi000246: 抱著離職的決心就可以唷 07/02 09:12
推 Csongs: 估開發時間就是要把測試考慮進去啊 07/02 09:14
→ allenxxx: 你如果在開發團隊中夠力,可以去做,不然最好先找下一家 07/02 09:31
→ allenxxx: 有沒有想過你改了人家東西,原負責人拒絕維護誰會死 07/02 09:32
→ allenxxx: 你可以接下他的工作嗎? 07/02 09:32
→ allenxxx: 這行亂動不屬於自己的東西來配合自己想法,是大忌! 07/02 09:34
→ umum29: 團隊若實行code review和ticket system 哪有不能改的程式 07/02 09:38
→ umum29: 我待過工廠IT也待過agile開發 製造業IT很符合樓上的說法 07/02 09:39
噓 DCTmaybe: 他之前寫的程式還有在幫公司賺錢就是對的 07/02 10:34
推 a926: 這是在釣魚？ 07/02 10:36
→ Masakiad: 程式對不對跟spec上怎麼定義有關，怎麼會跟有沒有測試 07/02 11:10
→ Masakiad: 有關？一開始的核心概念沒搞懂你才會問這樣的問題 07/02 11:10
推 strike5566: 說的很對，反正績效算你的，技術債上門時大概也升官 07/02 12:09
→ strike5566: 跳槽了 07/02 12:09
推 brucetu: 反正改壞了出包你負全責不要推託說原本的code很爛 07/02 12:39
→ brucetu: 那你愛怎麼改都可以 07/02 12:39
→ leo5916267: 寫測試也要懂以前的邏輯脈絡，但會重構就是以前的程 07/02 12:50
→ leo5916267: 式混雜一起 07/02 12:50
→ leo5916267: 到最後大家都不想補技術債，只想亂寫，然後bugfix在 07/02 12:51
→ leo5916267: 丟給菜鳥亂補 07/02 12:51
推 Csongs: 真的很少接到舒服的code 07/02 12:52
推 sniper2824: 你考機想吃餅我沒意見啊 07/02 12:59
推 king22649: 把這時間省下來 刷leetcode、練英文比較實在 07/02 13:08
→ deray: 工啥小啦幹 07/02 13:36
推 Masakiad: 推文看下來覺得這些系統真的很堪憂阿 07/02 13:56
→ cphe: 這老議題了... 07/02 14:00
→ NTULioner: 工作不要出包最重要 07/02 14:20
→ NTULioner: 改好 上面不覺得有功 改爛馬上變戰犯 07/02 14:21
噓 annheilong: 怎麼證明之前的對不對 不就是寫測試去驗證嗎... 07/02 14:23
→ shooter555: 就是遇過有人說要重構 然後也重構了 結果一堆bug又不 07/02 14:33
→ shooter555: 修 然後只好等下一個人來重構loop? 07/02 14:33
→ Masakiad: 樓上，所以才要先寫測試後才重構，然後重構目標跟debug 07/02 15:01
→ Masakiad: 完全不同，怎麼回有bug結果又重構這種操作？ 07/02 15:01
噓 as23041248: 時程都不允許還重構0.0 07/02 15:04
噓 alihue: 其實寫測試可以讓重構更快 07/02 15:24
推 luke72: 菜鳥 程式出包責任是你扛還是前輩扛 別人扛責你幹嘛管 07/02 15:31
→ luke72: 很多東西是有歷史因素的 沒搞清楚就亂重構容易出事 07/02 15:32
→ shooter555: 重構者不繼續維護 然後接任者有起了重構的心 loop就出 07/02 15:34
→ shooter555: 現了 07/02 15:35
→ shooter555: *又 07/02 15:35
→ shooter555: 現實中遇過因為架構上限制包含整個協議重構 結果重構 07/02 15:37
→ shooter555: 後的東西太多問題不能用 省下重構時間想個新產品來玩 07/02 15:40
→ shooter555: 說不定還比較好 07/02 15:40
→ Darkword1987: 要改可以 出錯你扛 本來就是這樣了啊 07/02 16:31
→ Masakiad: 每次都要把什麼擔責任加進來討論，重點就算有授權這邊也 07/02 16:55
→ Masakiad: 一堆人搞不懂怎麼重構 07/02 16:55
推 sharku: 爛 code 是造成 delay 跟 online issue 的元兇 07/02 17:10
→ ssccg: 會動不就是對的? 不然還能叫會動嗎? 07/02 17:22
→ ssccg: 不是重構要寫測試，是有測試比較好重構，沒測試你重構完了 07/02 17:25
→ ssccg: 還不是要手動測好測滿? 07/02 17:26
→ allenxxx: 測試之前也要先理解業務流吧,很多很奇特的你認為的狗屁 07/02 17:44
→ allenxxx: 邏輯其實都是有歷史典故而且不得不做的,當特例變成客戶 07/02 17:45
→ allenxxx: 常規,你要不要配合?那你看不懂自作聰明修了...保重 07/02 17:46
→ bheegrl: 有些邏輯寫錯的改成對的是會出事的== 07/02 17:48
推 vencil: 其實是本來就該測試了 不是等到重構才在想 07/02 18:18
推 mpjp: 你又怎麼知道你寫的是對的XD 07/02 18:30
推 hichcock: 先下手再說 07/02 18:47
噓 xephon: 改成你以為的正確可能會出事 07/02 19:12
推 Ekmund: 後來看前輩的操作是，把需求摸透，甚至說服上面的需求範 07/02 19:48
→ Ekmund: 圍後，在還沒被授意前就硬幹前幾段提初步成果再說。 07/02 19:48
→ Ekmund: 反正頭洗下去結果好看，頂頭多會給你試，要縮成本也不高 07/02 19:50
→ foreverk: 那是你的前輩credit夠多可以燒，一般人先斬後奏的下場 07/02 19:52
→ foreverk: 都不是太好 07/02 19:52
推 devilkool: 推Masa大 07/02 21:03
推 t64141: 我的操作跟E大前輩差不多，不過是先在本機做實驗樣品，覺 07/02 21:03
→ t64141: 得可行再去說服上面後才會真的正式做/commit 07/02 21:03
→ t64141: 或是趁著需求變更順便做效果也不錯 07/02 21:11
→ GoodFriday: 小範圍重構免強睜一隻眼閉一隻眼說肉眼可判斷不會出錯 07/02 22:50
→ GoodFriday: 大範圍重構還不寫測試是想? 07/02 22:51
推 clamperni: 可憐哪 還在重構 07/02 22:54
→ v7q4: 一池豬屎，好不容易經過時間的累積，終於表面乾掉不會臭，就 07/02 23:08
→ v7q4: 沒必要去攪動它了！ 07/02 23:08
→ Ghamu: 目前手上的程式連文件spec 都沒有 所以我隨便改沒差 07/02 23:49
推 Nonegrame: 上班沒空寫測試 下班寫啊 就這麼簡單 07/03 00:24
推 jasonwung: 你終究要作測試驗證，何不一開始就寫測試 07/03 00:32
→ siriusu: 大家講的差不多了，測試就是幫助確認品質，而已經上線過 07/03 08:15
→ siriusu: 的系統某種程度就是就過驗證的；所以不要偏離原本的行為 07/03 08:15
→ siriusu: 是有價值的，就看這個價值對你來說有多少（系統多少人使 07/03 08:15
→ siriusu: 用、是不是完全不能出錯的系統） 07/03 08:15
推 bnd0327: 直接改下去，萬一發現改不好不是進退兩難? 07/03 10:27
噓 InvincibleK: 長官沒說改,就別動嘿 07/03 15:06
→ meowyih: 就算不說測試，你怎麼證明你寫的會比原來的好？你覺得你 07/03 20:51
→ meowyih: 寫的比較好debug那只是因為是自己寫的啊，你走人後別人也 07/03 20:51
→ meowyih: 會這麼認為嗎？顆顆 07/03 20:51
→ Masakiad: 會啊，之後還請我做consultant 07/03 21:36
推 APTON: 比較殘酷的是....說沒時間寫測試的，實際給了時間還是寫不 07/04 10:47
→ APTON: 出來QQ 07/04 10:47
推 play1921: 還沒有真的user勇敢改不要怕 有真的user就問問看pm 07/04 11:19
噓 daddy29: 妳問題比較大 開發時程不夠兩件事 1.能力不足 2.看不清 07/04 11:42
→ daddy29: 等級在哪邊 還想要重構 07/04 11:42
推 lukelove: 嘻嘻 你確定你改完會比較好維護? 一堆越構越爛邏輯越複 07/04 12:03
→ lukelove: 雜的例子 07/04 12:03
推 stupid0319: 你的實力沒被認同才會被這樣說,只能靠你自己証明 07/04 16:23
→ stupid0319: 如果你很強,怎麼做都是可行的 07/04 16:24
→ panbanana: 要了解架構才能寫出好的，有意義的測項吧 07/04 17:22
→ panbanana: 沒有了解，你能確定你的測法是正確的嗎 07/04 17:23
推 mathrew: 因為你只是改成你認為正確的，事實上現在運作沒出大問題 07/05 12:18
→ mathrew: 也許你寫出來的只是對你來說 你比較好debug 07/05 12:20
→ mathrew: 因為是你寫的，所以你會知道問題在哪，但對別人來說不是 07/05 12:20
→ Ghamu: 其實應該說清楚一點 本來程式一大球 好幾行 分崩離析 拆成 07/06 01:27
→ Ghamu: 小分小分 即使有錯也比一整包天書好解決吧 07/06 01:27
推 highwayshih: 啊人家就會動沒出錯 哪會比你沒寫測試重構出錯差? 07/06 07:25
推 highwayshih: 爛code至少用能動說服大家它能用了 你連測試都不想寫 07/06 07:29
→ highwayshih: 要怎麼說服別人重構會比較好? 07/06 07:29
→ rodion: 原PO似乎弄錯測試程式的目的了? 測試是為了確保行為一致 07/06 17:20
→ rodion: 輸出正確與否 不是測試程式應該著力的點 07/06 17:21






... <看更多>

設計 重 構 25個管理技術債的技巧消除軟體設計 臭 味 在 設計重構：25個管理技術債的技巧消除軟體設計臭味 - Facebook 的推薦與評價

本書重點介紹了 技術債 和一種確實可行的 技術債管理 方式，是一部名副其實的 臭味 實戰指南。 ──Grady Booch（IBM 研究院院士兼 軟體 工程首席科學家） 本書是 ... ... <看更多>

設計 重 構 25個管理技術債的技巧消除軟體設計 臭 味 在 構設計設計費2023-精選在Youtube/網路影片/Dcard上的焦點 ... 的推薦與評價

公共建設之工程計畫作業程序大致分為規劃、設計及施工等三階. 段重大之公共工程計畫 ... 設計重構：25個管理技術債的技巧消除軟體設計臭味- ... ... <看更多>

設計 重 構 25個管理技術債的技巧消除軟體設計 臭 味 在 構設計設計費2023-精選在Youtube/網路影片/Dcard上的焦點 ... 的推薦與評價

公共建設之工程計畫作業程序大致分為規劃、設計及施工等三階. 段重大之公共工程計畫 ... 設計重構：25個管理技術債的技巧消除軟體設計臭味-&nbsp;... ... <看更多>

設計 重 構 25個管理技術債的技巧消除軟體設計 臭 味 在 軟體設計原則DRY (Don't repeat yourself) 的推薦與評價

DRY (Don't repeat yourself)，是敏捷開發的核心設計原則之一。 ... DRY原則的誤區; 設計重構：25個管理技術債的技巧消除軟體設計臭味 ... ... <看更多>

你可能也想看看
搜尋相關連結

#1. 設計重構：25個管理技術債的技巧消除軟體設計臭味 ...

設計重構 ：25個管理技術債的技巧消除軟體設計臭味(Refactoring for Software Design Smells: Managing Technical Debt) ; ISBN · 9864345222 ; ISBN-13 · 9789864345229 ; 商品 ...

#2. 設計重構：25個管理技術債的技巧消除軟體設計臭味

書名：設計重構：25個管理技術債的技巧消除軟體設計臭味，語言：中文繁體，ISBN:9789864345229，出版社:博碩文化，作者:Girish Suryanarayana，出版日期:2021/10/07， ...

#3. 設計重構：25個管理技術債的技巧消除軟體設計臭味

設計重構 ：25個管理技術債的技巧消除軟體設計臭味 ; 410元. 快速到貨 · 520 · Girish Suryanarayana · 博碩文化追蹤 · 平裝.

#4. 設計重構：25個管理技術債的技巧消除軟體設計臭味 - Facebook

本書重點介紹了 技術債 和一種確實可行的 技術債管理 方式，是一部名副其實的 臭味 實戰指南。 ──Grady Booch（IBM 研究院院士兼 軟體 工程首席科學家） 本書是 ...

#5. 《設計重構》讀後分享

《設計重構》主要分享程式設計上的壞味道，用實例分享如何識別壞味道，並給予重構上的優化建議.

#6. 設計重構：25個管理技術債的技巧消除軟體設計臭味 ...

【3dWoo 大學簡體電腦書店】購物車 ; 書名, 出版社 ; 1, 設計重構：25個管理技術債的技巧消除軟體設計臭味, 博碩 ; 書款：. 390. 元+ 運費：. 待進入結帳中心計算. + 二次運費.

#7. 雙11主打設計重構25個管理技術債的技巧消除軟體設計臭味

雙11主打設計重構25個管理技術債的技巧消除軟體設計臭味圖書價格,圖書搜尋,二手書、電子書圖書比價,全台各大圖書館館藏快速查詢;出版日期新到舊;第1頁,讓您輕鬆尋找想 ...

#8. 設計重構的價格推薦- 飛比2023年05月即時比價

設計重構 ：25個管理技術債的技巧消除軟體設計臭味(Girish Suryanarayana/Ganesh Samarthyam/Tushar Sharma) 墊腳石購物網. 468. 蝦皮商城. 促銷 蝦皮週三免運日!

#9. 為何會欠下技術債？ - iT 邦幫忙

技術債 會讓程式碼難以修改，而重構的目的之一，正是改善設計並讓其他人更容易地理解程式碼，換言之，重構正是在還債。 技術債跟信用卡的循環利息一樣，如果置之不理，會像 ...

#10. 設計軟體的價格推薦- 2023年5月

包含3062筆拍賣、399筆商城.「設計軟體」哪裡買、現貨推薦與歷史價格一站比價，最低價格都在BigGo！ ... 設計重構：25個管理技術債的技巧消除軟體設計臭味.

#11. 《設計重構》第一章心得& 推坑

請放心，這本書談的是結構設計層級的技術債、壞味道，與如何重新打造給“很醜程的程式碼” 的修正空間。 意思是這本書不會浪費篇幅，教你怎麼處理coding style、怎麼為函式 ...

#12. 程式語言(電腦) - 分類精選- 2023年4月

Python零基礎入門班（第三版）：一次打好程式設計、運算思維與邏輯訓練 ... 設計重構：25個管理技術債的技巧消除軟體設計臭味[二手書_良好]0066 TAAZE讀冊生活.

#13. 插圖管理｜誠品線上

誠品線上有眾多插圖管理相關商品，讓誠品全方位包辦您的生活大小事。 ... 克服倦怠和低潮的86個心靈紓壓祕方 ... 設計重構: 25個管理技術債的技巧消除軟體設計臭味.

#14. Refactoring - 卡哥小技倆

為了解決這個問題，可以使用Strategy Pattern來重構switch case block。 ... 技術負債（英語：Technical debt），又譯技術債，也稱為設計負債（design debt）、程式碼 ...

#15. 從2022 暢銷書單檢視年度的閱讀情形

Soft Skills 軟實力｜軟體開發人員的生存手冊 ... 78, 設計重構：25個管理技術債的技巧消除軟體設計臭味(Refactoring for Software Design Smells: ...

#16. 「物件導向的再造模式」電子書PDF 免費下載 - Ruyut 鹿遊

最近買了一本新書——「設計重構：25個管理技術債的技巧消除軟體設計臭味(Refactoring for Software Design Smells: Managing Technical Debt)」.

#17. 图书港台图书工業/建築/計算機品牌优惠商品大全 - 虎窝购

预订台版设计重构25个管理技术债的技巧消除软件设计臭味博硕Girish Suryanarayan. 0评价灵感库图书专营店. 抢购 · 预订台版物联网原来这么近立即手动实作一个(超效 ...

#18. 基礎知識揭密(第二版)9786263331471博碩MP22232 520

【大享】 計算機組成原理－基礎知識揭密與系統程式設計初步9789864347520博 ... 益大資訊~設計重構：25個管理技術債的技巧消除軟體設計臭味9789864345229 博碩MP12006.

#19. 構設計設計費2023-精選在Youtube/網路影片/Dcard上的焦點 ...

公共建設之工程計畫作業程序大致分為規劃、設計及施工等三階. 段重大之公共工程計畫 ... 設計重構：25個管理技術債的技巧消除軟體設計臭味- ...

#20. 聊一聊为什么不重构呢？

重构 是提高质量的重要工具。许多开发方法都依赖于重构，尤其是对于敏捷方法，在更多计划驱动的组织中也是如此。但事实上，是否以重构来处理设计中的某 ...

#21. 自承认技术债的研究: 问题、进展与挑战

可见, 所有的设计债都是非最优决策的结果. 偿还: 通过代码重构或者对其重新实现来解决. 样例: 在如下样例中, 该注释指出该方法 ...

#22. [討論] 重構之前要寫測試不然不要重構- 看板Soft_Job

作者Ghamu (貓丸). 看板Soft_Job · 看板Soft_Job · 標題[討論] 重構之前要寫測試不然不要重構 · 時間Thu Jul 2 02:48:37 2020 · 推ousapas: 如果是老程式碼可以把手測 ...

#23. 论文精讲| 盘点机器学习系统中7大技术债类型

常见的坏味道（Common Smells）：在软件工程中，设计味道（design smell）可能表示组件或系统中的潜在问题。在此，也列举几个机器学习系统中几个常见的坏 ...

#24. 重構(Refactoring) 學習心得筆記— 壞味道(Bad Smell / Code ...

比方說大量使用switch敘述跟if敘述，充滿分歧的流程處理，或是大量使primitive variables (int, double…etc)，不建立專用的類別，這讓程式不夠物件 ...

#25. 中華民國職業標準分類

構 變遷及利於與國際接軌，以聯合國國際職業標準分類為 ... 圍，分為4 個技術層次，主要應用於大類之劃分，可依工 ... 2512 軟體開發及程式設計師.

#26. 整洁代码之道——重构

谈论到何谓代码的坏味道，重复代码（Duplicated Code）首当其冲。重复在软件系统是万恶的, 我们熟悉的分离关注点，面向对象设计原则等都是为了减少重复 ...

#27. 重构：改善既有代码的设计（第2版）（异步图书）【世界软件开发 ...

书中给出了60多个可行的重构，每个重构都介绍了一种经过验证的代码变换手法的动机和技术。本书提出的重构准则将帮助开发人员一次一小步地修改代码，从而减少了开发过程中的 ...

#28. 心得想轉職前端工程師？你該先好好認識這個職業

近年前端工程師Front-End Developer是個熱門職業使不少原職是美術設計師、UI/UX設計師 ... （Jira、Trello之類的專案管理軟體，或者試算表上的項目）.

#29. 提升编程效率：重构

只能说是精神可嘉，但是方法不对。 重构产出了持续演进的代码设计，并消除日常代码中的坏味道，那么当新的需求到来，或者原油 ...

#30. 軟體設計原則DRY (Don't repeat yourself)

DRY (Don't repeat yourself)，是敏捷開發的核心設計原則之一。 ... DRY原則的誤區; 設計重構：25個管理技術債的技巧消除軟體設計臭味 ...

#31. P2P托管可靠性存疑平台与资金真隔离是关键

顾崇伦认为，最简单的托管模式是第三方支付机构采用的备付金管理模式，即第三方支付将用户资金以备付金形式托管在银行；第二种可能的托管形式是在备付 ...